Fenwick Tree Updates #4803
Fenwick Tree Updates #4803
Conversation
for more information, see https://pre-commit.ci
Co-authored-by: Kevin Sheng <55369003+SansPapyrus683@users.noreply.github.com>
Co-authored-by: Kevin Sheng <55369003+SansPapyrus683@users.noreply.github.com>
for more information, see https://pre-commit.ci
content/5_Plat/2DRQ.mdx
Outdated
| class BIT2D { | ||
| /** | ||
| * Offline 2D Fenwick Tree implementation. | ||
| * Note that n needs to be of a reasonable size, and |
There was a problem hiding this comment.
what does reasonable size mean
There was a problem hiding this comment.
maybe i should just specify that the rows aren't coordinate compressed in the template itself
There was a problem hiding this comment.
perhaps smth smth "memory takes up is O(n^2) actually haha"
There was a problem hiding this comment.
no it doesnt take O(n^2) memory tho lmao, which is why its actually kinda useful
its like O(n log n) memory or similar, depending on the # of update queries
There was a problem hiding this comment.
well i guess n=1e5 would work?
There was a problem hiding this comment.
yeah n=1e5 won’t tle
There was a problem hiding this comment.
i mean then i'm not sure why this warning is necessary
when does this start breaking down
There was a problem hiding this comment.
i'd guess n=1e6 or n=1e7
the main reason is because the # of columns can scale to a stupid big number (cuz we are coordinate compressing), but we aren't coordinate compressing the rows here for the sake of making the implementation easier
Co-authored-by: Kevin Sheng <55369003+SansPapyrus683@users.noreply.github.com>
Co-authored-by: Kevin Sheng <55369003+SansPapyrus683@users.noreply.github.com>
…iative/usaco-guide into 2DRQ-Fenwick-Tree-Updates
for more information, see https://pre-commit.ci
| @@ -418,7 +441,7 @@ int main() { | |||
|
|
|||
| <Warning title="Implementation Note"> | |||
|
|
|||
| As mentioned earlier, the above `BIT2D` implementation is significantly slower than Benq's `OffBIT2D` and, in fact, will get TLE on the Soriya's Programming Project; this is due to the large amount of calls to `vector.resize` it makes. | |||
| As mentioned earlier, the above `OfflineBIT2D` implementation is significantly slower than Benq's `OffBIT2D` and, in fact, will get TLE on the Soriya's Programming Project. | |||
There was a problem hiding this comment.
i think you can still explain why it's slower
There was a problem hiding this comment.
ok the thing is the previous explanation for why it got constant factored is wrong tho (or maybe I am underestimating the space complexity for this problem) because it doesn't call .resize all that many times
so I'm p sure it just gets constant factored out in this case
idk if benq's passes, but if it does it's because he does some cursed stuff and actually flattens out the binary indexed trees into just one really big binary indexed tree
Place an "x" in the corresponding checkbox if it is done or does not apply to this pull request.
I have tested my code.
I have added my solution according to the steps here.
I have followed the code conventions mentioned here.
I have linked this PR to any issues that it closes.
added a (in my opinion) cleaner 2d bit impl (which is also more in line w/ the PURS bit impl)
added a slightly different verison of the offline bit impl
indfunction as a reference